Asynchronous messaging is a widely used means of communication between loosely coupled participant systems engaged in a collaborative process such as, e.g., an electronic business process involving distributed business partners. Generally, a collaborative process is one that is characterized by a plurality (two or more) of participants collaborating through exchange of messages in order to accomplish an overall goal or result. Collaborative business processes can be conducted among participants within a single enterprise. They can also involve business partners from different enterprises. Electronic financial controlling/budgeting systems, electronic material resource planning/controlling systems, and electronic purchase/sales order systems are but examples of modern electronic business/commerce applications that may involve collaborative processes of distributed participants, or clients.
Generally, a participant system engaged in a computer-implemented collaborative process can be viewed as comprising the entirety of hardware and software components required to make up a full-fledged participant to the process. In a more specific perspective, a participant system is formed by a software system implemented and executed on a computer and providing one or more software applications capable of consuming and producing messages received from, and sent to, other participant systems. The participant system may include, or have access to, one or more databases allowing storage of various application-related data such as, e.g., financial figures, fabrication figures, stock figures, etc. The messages exchanged between the participant systems may, e.g., contain requests or reports specifying business actions. The exchange of the messages is asynchronous in that an application sending a message does not need to wait for a remote application to receive that message. Thus, there is no need for all elements of the infrastructure linking the participant systems to be available at all times.
A conventional way of specifying a collaborative process is using UML (Unified Modeling Language) state chart diagrams, one for each participant system. These state chart diagrams specify local states that can be assumed by the participant systems in the course of the collaborative process. Additionally, the state chart diagrams specify local state transitions the participant systems may undergo. Local state transitions are defined by a starting local state, a target local state, a triggering event and a resulting event. The starting local state and the target local state can be different, or be the same. In the first case, the respective participant system experiences a transition from one local state to another, in the second case, a transition-to-self. A triggering event can, e.g., be a message transmitted over the messaging network from another participant system. It can also be a local event unrelated to communication over the messaging network, e.g., a data input through a local user interface or by another local software application. A triggering event can even be a message that is outside the scope of the process analysis. From the sight of the process model, such external message can be triggered as unmotivated as any local event due to, e.g., user action or batch transaction. Similarly, a resulting event can include the sending of a message to another participant system and/or an event local to the respective participant system, e.g., an output of data for display on a monitor or storage in a database.
Optimally, a collaboration specification deals with every possible scenario of occurring messages and local states of the participant system. However, when developing a collaborative process it may easily happen that one or more potentially occurring scenarios are not considered and remain unspecified. If the collaboration process is implemented using a specification that is incomplete, such unspecified situations lead to errors in the collaboration. The user typically does not have a straight solution for this problem. This requires that a provider of customer support be informed, causing costs for maintenance. In some instances these costs can be small compared with losses in revenue or business that may result from the failure.
For humans it is a hard to achieve a fully consistent and complete collaboration specification. Only very experienced personnel will be capable of doing so. This is particularly true as the complexity of the collaboration specification grows dramatically with the number of messages that can be communicated. Even harder is it to achieve this goal of completeness of the process specification in a distributed team of developers, a case normal in today's world of software development. It is therefore highly desirable to provide a developer engaged in developing a specification for a collaborative process with a tool that supports him in achieving a complete and consistent process specification.